1. Field of the Invention
The present invention relates to controllers, such as, for example, microcontrollers, microprocessors and the like, as are, for example, employed in ASICs (application specific integrated circuit), SOCs (system on chip) and the like, and, in particular, to controllers basing on a CPU architecture (CPU=central processing unit) which do not support an addressing of a memory size required.
2. Description of the Related Art
Although the development of microprocessors and microcontrollers has led to considerable performance increases, in certain technological fields of application, such as, for example, in the chip card area or in SOC designs, older CPU architectures are preferred to newer architectures when integrating a CPU in an integrated circuit. A reason for this is that newer CPU architectures having a higher performance are often oversized for the respective field of application provided and thus, as regards the tasks to be performed, require too much power and take up too much chip area. Another reason for preferring an older CPU architecture to a newer, more powerful one is that the software development environment for the older CPU architectures, such as, for example, the 8051- or 8052-based microcontroller architecture, is often more popular with customers, and that more software developers are available for them.
The problem of the software development environment, more popular with customers, for older controller architectures is of particular importance in the chip card area, since in this case the generation of the machine programs which can be processed on the chip card or of executable machine codes does not fall into the responsibility of the chip manufacturer but, for reasons of safety, of major customers, such as, for example, banks and their software development companies, and of the respective operating system developing company. In addition, due to the high numbers required, it is of enormous importance for the chip card customers to use chip card controllers adapted to the respective requirements in order to keep the cost as low as possible. In order to satisfy the low-end chip card area and to meet the desire of some customers for well-known software developing environments, the chip card manufacturer consequently has to be in a position to offer chip cards basing on an older microcontroller architecture.
A problem in using older controller architectures in chip card manufacturing, however, is that their ways of addressing are not sufficient. Thus, in the chip card area, the capability of an 8051-based CPU is basically sufficient to take over the managing tasks of a chip card, but for reasons of high safety requirements, cryptography algorithms which include calculating operations in relation to very large operands must be processed on the chip card by cryptocoprocessors. In the well-known RSA (Rivest, Sharmir and Adleman) algorithm, operand lengths of, for example, 1024 are usual. Due to these large operand lengths to be processed and the complexity of the cryptography algorithms themselves, access to the largest possible memory is required in chip cards. Here, the problem of using CPUs basing on older controller architectures is that they only allow an addressing of small memory sizes. 8051-based CPUs, for example, only allow an addressing of 64 kbytes.
A possible solution for rendering addressable a large memory despite the usage of a controller having an older architecture is to use externally stored descriptors or basis addresses determining the position of a memory window addressed by the CPU so that the memory area addressable by the CPU can be shifted over the entire larger memory by means of the memory window. FIG. 4 shows a block diagram of an 8-bit controller generally indicated at 800 and consisting of an 8051-based CPU 805 and an MMU (memory management unit), and a memory 815 connected to the controller 800, which can consist of different memory types, such as, for example, a read-only memory (ROM), a random access memory (RAM), a non-volatile memory (NVM), such as, for example, an EEPROM or a flash memory, and the like, and is only illustrated as a block for a better understanding. The CPU 805 is connected, via an 8-bit address line 820 and a bidirectional 8-bit data line 825, to the MMU 810 which, in turn, is connected to the memory 815 via a 12-bit address line 840 and a bidirectional 8-bit data line 845. In the case of a chip card, the controller 800 is, for example, connected to further components, such as, for example, a cryptocoprocessor for performing cryptography algorithms, an interrupt module, a contact or contactless interface for performing the communication to a terminal, a random number generator and further components, which are not illustrated in FIG. 4 for simplification.
A problem with the controller 800 of FIG. 4 is that the CPU 805 is based on an 8-bit architecture and, as regards its command set 855, only allows an addressing of 64 kbytes, while the size of the memory 815, in the case of a chip card, must be larger and, in the example of FIG. 4, is for example one megabyte. The reason why only 64 kBytes are addressable for the CPU 805 is that in data accesses by means of the command set 855, and, in particular, by means of the read/write commands, such as, for example, the MOV commands, and in code accesses for producing an address, only two bytes (16 bits) are used which only allow coding of 216=64 k states.
When executing a read command, the CPU 805 outputs the 16-bit address on the 8-bit address line 820 and the 8-bit data line 825. As a response, the CPU 805, on the data lines 825, waits for the memory contents of the memory 815 at the address required. In order to enable addressing the 1-MB memory 815, a data descriptor 860 is stored outside the CPU 805 in the MMU 810 indicating a basis address added to the 16-bit address by the CPU 805, whereupon the result is output on the 12-bit address line 840 and the 8-bit data line 845 for addressing to the memory 815. In this way, a 64 k data memory window 865 in the memory 815 is defined by the descriptor 860, the starting address of which corresponds to the basis address indicated by the descriptor 860. By providing the descriptor 860 and the MMU 810, it is ensured that the CPU 805 will always access the memory window 865 in memory accesses in relation to the memory 815, wherein the address output by the CPU 805 indicates the offset of the byte to be read within the memory window 865. The CPU 805 executes a write or read command, wherein the MMU 810 translates the 16-bit address from the CPU 805 into a physical 20-bit address and redirects the access correspondingly.
Although the concept of the descriptor 860 can be extended to any memory sizes in connection with the MMU 810, it is of disadvantage in that, in memory accesses to addresses of the memory 815 outside the memory window 865, the MMU 810 must first be reconfigured, i.e. the descriptor 860 must be reset correspondingly. This reconfiguration of the MMU 810 is especially complicated since it requires a software-setting of the descriptor 860 and since, in a memory continually visible (i.e. addressable) for the CPU 805, a managing code 870 must be stored, including an MMU setting code for setting the descriptor 860, which reduces the memory directly addressable, which is mostly very small anyway. In addition, the setting of the descriptor 860 requires additional clock cycles, which reduces the operating speed of the controller. Assuming the memory sizes indicated above, the duration for a data access to a memory address of the memory 815 outside the memory window 865, for a compiled program, is, for example, 140 clock cycles compared to 4 clock cycles for memory accesses within the current memory window 865.
The problem of the MMU reconfiguration increases in the area of code accesses wherein, in a corresponding way, a code descriptor 875 defines a code memory window 880, in that, when executing subprograms, i.e. call commands, in memory areas outside the memory window 880, the return jump into the currently set memory window 880 must be ensured. While only the code descriptor 875 must be reset when leaving the currently set memory window 880 while processing the machine code in the normal command sequence, i.e. when there is no jump command, or in jump commands without return intention, like in data accesses, it must be ensured in jump commands with return intention that, in the case of the return jump, the code descriptor 875 is set to the original value. In order to ensure this, the managing code 870 must further comprise an initializing code called in each jump command with return intention relating to a destination outside the currently set code memory window 880 to ensure the restoration of the descriptor settings before the jump when returning.
A possible software-realization is to provide, for each bank, i.e. each possible memory window position, of the memory 815, an initializing code and a setting and resetting code organized in a table and stored in the continually visible memory area of the memory 815. In order to perform a jump command with return intention beyond the limits of the currently set memory window 865, a jump command with return intention, from a program code, into a function in the continually visible memory area must take place, loading, into an internal register 885, such as, for example, a data pointer DPTa, the 16-bit address of the destination code in relation to the destination bank, i.e. the offset within the destination bank, where the command to which has been jumped is, and subsequently calling the initializing code with a jump command without return intention into the continually visible memory area. By executing the initializing code, the address of the MMU resetting code for recovering the currently set window 880 or the current bank is at first shifted to a stack or stack memory 890, then the address written before into the internal register 885 is shifted to the stack 890 and finally the MMU setting code for the new destination MMU bank is called by a jump command without return intention. At the end of the setting code, after MMU reconfiguring has taken place, a jump is performed to the desired function or the desired subprogram in the new set memory window with a return jump command. After processing the function, the MMU resetting code for restoring the original MMU configuration or for recovering the originally set memory window 880 is called by a return command to recover the original MMU setting. The return jump command at the end of the resetting code then, within the newly set memory window 865, jumps to the corresponding following position in the program code. In order to be able to reset the MMU 810 by means of the CPU commands contained in the MMU setting or resetting code, either special commands can be provided with which the CPU 805 can address the MMU 810 and the descriptors 860 and 875, respectively, or the MMU 810 responds to reserved 8-bit addresses from the CPU 805 on the address and data lines 820 and 825.
In order to realize a memory area within the memory 815, continually addressable or visible for the CPU 805, not all the 16-bit addresses output by the CPU 805 are mapped by the MMU 810 to the memory window 865 but to a fixed memory area of the memory 815 so that the effectively addressable size of the memory window 865 is reduced by the managing code 870.